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Abstract 


This document describes extensions to Multi-Protocol Label Switching 
(MPLS) Constraint-—based Routed Label Distribution Protocol (CR-LDP) 
Signaling required to support Generalized MPLS. Generalized MPLS 
extends the MPLS control plane to encompass time-division (e.g., 
Synchronous Optical Network and Synchronous Digital Hierarchy, 
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., 
incoming port or fiber to outgoing port or fiber). This document 
presents a CR-LDP specific description of the extensions. A generic 
functional description can be found in separate documents. 
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1. Introduction 


Generalized MPLS extends MPLS from supporting packet (PSC) interfaces 
and switching to include support of three new classes of interfaces 
and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and 
Fiber-Switch (FSC). A functional description of the extensions to 
MPLS signaling needed to support the new classes of interfaces and 
switching is provided in [RFC3471]. This document presents CR-LDP 
specific formats and mechanisms needed to support all four classes of 
interfaces. RSVP-TE extensions can be found in [RFC3473]. 


[RFC3471] should be viewed as a companion document to this document. 
The format of this document parallels [RFC3471]. It should be noted 
that the RSVP-TE specific version of Generalized MPLS includes RSVP 
specific support for rapid failure notification, see Section 4 
[RFC3473]. For CR-LDP there is not currently a similar mechanism. 
When a failure is detected it will be propagated with 
RELEASE/WITHDRAW messages radially outward from the point of failure. 
Resources are to be released in this phase and actual resource 
information may be fed back to the source using a feedback 
mechanisms. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2. Label Related Formats 


This section defines formats for a generalized label request, a 
generalized label, support for waveband switching, suggested label 
and label sets. 


2.1. Generalized Label Request 


A REQUEST message SHOULD contain as specific an LSP (Label Switched 
Path) Encoding Type as possible to allow the maximum flexibility in 
switching by transit LSRs. A Generalized Label Request Type, Length, 
and Value (TLV) is set by the ingress node, transparently passed by 
transit nodes, and used by the egress node. The Switching Type field 
may also be updated hop-by-hop. 


The format of a Generalized Label Request is: 


0 1 2 3 
012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


|u]F | Type (0x0824) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| LSP Enc. Type | Switching Type | G-PID 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
See [RFC3471] for a description of parameters. 
2.1.1. Procedures 


A node processing a REQUEST message containing a Generalized Label 
Request must verify that the requested parameters can be satisfied by 


the incoming interface, the node and by the outgoing interface. The 
node may either directly support the LSP or it may use a tunnel (FA), 
i.e., another class of switching. In either case, each parameter 


must be checked. 


Note that local node policy dictates when tunnels may be used and 
when they may be created. Local policy may allow for tunnels to be 
dynamically established or may be solely administratively controlled. 
For more information on tunnels and processing of ER (Explicit Route) 
hops when using tunnels see [MPLS-HIERARCHY]. 


Transit and egress nodes MUST verify that the node itself and, where 
appropriate, that the outgoing interface or tunnel can support the 
requested LSP Encoding Type. If encoding cannot be supported, the 
node MUST generate a NOTIFICATION message, with a "Routing 
problem/Unsupported Encoding" indication. 
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Nodes MUST verify that the type indicated in the Switching Type 
parameter is supported on the corresponding incoming interface. If 
the type cannot be supported, the node MUST generate a NOTIFICATION 
message with a "Routing problem/Switching Type" indication. 


The G-PID parameter is normally only examined at the egress. If the 
indicated G-PID cannot be supported then the egress MUST generate a 
NOTIFICATION message, with a "Routing problem/Unsupported G-PID" 
indication. In the case of PSC and when penultimate hop popping 
(PHP) is requested, the penultimate hop also examines the (stored) 
G-PID during the processing of the MAPPING message. In this case if 
the G-PID is not supported, then the penultimate hop MUST generate a 
NOTIFICATION message with a "Routing problem/Unacceptable label 
value" indication. The generated NOTIFICATION message MAY include an 
Acceptable Label Set, see Section 4. 


When an error message is not generated, normal processing occurs. In 
the transit case this will typically result in a REQUEST message 
being propagated. In the egress case and PHP special case this will 


typically result in a MAPPING message being generated. 
2.1.2. Bandwidth Encoding 


Bandwidth encodings are carried in the CR-LDP Traffic Parameters TLV. 
See [RFC3471] for a definition of values to be used for specific 
Signal types. These values are set in the Peak and Committed Data 
Rate fields of the Traffic Parameters TLV. Other bandwidth/service 
related parameters in the TLV are ignored and carried transparently. 


2.2. Generalized Label 
The format of a Generalized Label is: 


0 1 2 3 

0 1 2-3 4 5-6 7 -8-9 0 1 23-45 6 T78 9 OL. 2.3 A4 56 T 80 I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HHH 
|u|F| Type (0x0825) | Length 
Fot ato ta toto tata tata tato toto toto titetotat tata tata tatetitetitetet 
| Label | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


See [RFC3471] for a description of parameters and encoding of labels. 
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2.2.1. Procedures 


The Generalized Label travels in the upstream direction in MAPPING 
messages. 


The presence of both a generalized and normal label TLV in a MAPPING 
message is a protocol error and should treated as a malformed message 
by the recipient. 


The recipient of a MAPPING message containing a Generalized Label 
verifies that the values passed are acceptable. If the label is 
unacceptable then the recipient MUST generate a NOTIFICATION message 
with a "Routing problem/MPLS label allocation failure" indication. 
The generated NOTIFICATION message MAY include an Acceptable Label 
Set, see Section 4. 


2.3. Waveband Switching 


Waveband switching uses the same format as the generalized label, see 
section 2.2. The type 0x0828 is assigned for the Waveband Label. 


In the context of waveband switching, the generalized label has the 
following format: 


0 1 2 3 

L 2-3 4°35: 6° 7 -8.°9° 0-1 23.4 56078 39. OT 2.3.4 5-67-86 9: 0-41 
—+-4+-4-+-4+-4+-4-4+-4+-4-4+-4+-4-4-4+-4+-4+-4-4+-4+-4-4+-4+-4-4-4+-4+-4-4-4 
Type (0x0828) | Length | 
—+-4+-4-+-4+-4-4+-4+-4+-4+-4+-+4+-4+-4-4+-4+-4+-4-4+-4-4-4+-4+-4-4-4+-4+-4-4-4 
Waveband Id | 
—+-4+-4-4+-4+-4-4-4+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4-4-4+-4-4-4-4+-4+-4-4-4-4-4+ 
Start Label | 
—+-4+-4-4+-4+-4-4-4+-4-4-4+-4+-4+-4-4+-4+-4-4-4+-4-4-4+-4+-4-4-4+-4-4-4-4+-4-4+ 
End Label | 
—+-4+-4-4+-4+-4-4-4+-4-4-4+-4+-4+-4-4+-4-4-4-4+-4-4-4+-4-4-4-4+-4-4-4-4+-4-4+ 


| 
+ 
l 


IG 
+ — 
Ij 
+— + 


+— + — + — ++ 


See [RFC3471] for a description of parameters. 
2.3.1. Procedures 


The procedures defined in Section 2.2.1 apply to waveband switching. 
This includes generating a NOTIFICATION message with a "Routing 
problem/MPLS label allocation failure" indication if any of the label 
fields are unrecognized or unacceptable. 


Additionally, when a waveband is switched to another waveband, it is 


possible that the wavelengths within the waveband will be mirrored 
about a center frequency. When this type of switching is employed, 
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the start and end label in the waveband label TLV MUST be swapped 
before forwarding the label TLV with the new waveband Id. In this 
manner an egress/ingress LSR that receives a waveband label which has 
these values inverted, knows that it must also invert its egress 
association to pick up the proper wavelengths. Without this 
mechanism and with an odd number of mirrored switching operations, 
the egress LSRs will not know that an input wavelength of say L1 will 
emerge from the waveband tunnel as L100. 


This operation MUST be performed in both directions when a 
bidirectional waveband tunnel is being established. 


2.4. Suggested Label 


The format of a suggested label is identical to a generalized label. 
It is used in REQUEST messages. Suggested Label uses type = 0x904. 


Errors in received Suggested Labels MUST be ignored. This includes 
any received inconsistent or unacceptable values. 


Per [RFC3471], if a downstream node passes a label value that differs 
from the suggested label upstream, the upstream LSR MUST either 
reconfigure itself so that it uses the label specified by the 
downstream node or generate a NOTIFICATION message with a "Routing 
problem/Unacceptable label value" indication. Furthermore, an 
ingress node SHOULD NOT transmit data traffic using a suggested label 
until the downstream node passes corresponding a label upstream. 


2.5. Label Set 
The format of a Label Set is: 


0 ak 2 3 
0:1. 2. 3-4-5 6 7.8.90 12°34. 5-6 7 8.90: 12:3. 4 5° 6 °7 8.90 1 
Fatt ata ta tata tartar t arta tantantata ttt atta tata tata tatatatatatatat 
|U|F| Type (0x0827) | Length | 
Fatt ata ta tartar tartan ta tata tanta t ttt ato tata tatatatatatatatatat 

Action | Reserved | Label Type 
aa a a Sn Si Ss Se SS i ee H 
Subchannel 


+ — 
bh 


e+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


—4+-4-4-4-4-4-4-4-4-4-4+-4-4-4+-4+-4-4+-4+-4-4+-4-4+-4+-4-4-4-4+-4-4-4-4-4 


Subchannel 


eae Oar 
Zt 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
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Label Type: 14 bits 


Indicates the type and format of the labels carried in the TLV. 
Values match the TLV type of the appropriate Label TLV. 


See [RFC3471] for a description of other parameters. 
2.5.1. Procedures 


A Label Set is defined via one or more Label Set TLVs. Specific 
labels/subchannels can be added to or excluded from a Label Set via 
Action zero (0) and one (1) TLVs respectively. Ranges of 
labels/subchannels can be added to or excluded from a Label Set via 
Action two (2) and three (3) TLVs respectively. When the Label Set 
TLVs only list labels/subchannels to exclude, this implies that all 
other labels are acceptable. 


The absence of any Label Set TLVs implies that all labels are 
acceptable. A Label Set is included when a node wishes to restrict 
the label(s) that may be used downstream. 


On reception of a REQUEST message, the receiving node will restrict 
its choice of labels to one, which is in the Label Set. Nodes 
capable of performing label conversion may also remove the Label Set 
prior to forwarding the REQUEST message. If the node is unable to 
pick a label from the Label Set or if there is a problem parsing the 
Label Set TLVs, then the request is terminated and a NOTIFICATION 
message with a "Routing problem/Label Set" indication MUST be 
generated. It is a local matter if the Label Set is stored for later 
selection on the MAPPING message or if the selection is made 
immediately for propagation in the MAPPING message. 


On reception of a REQUEST message, the Label Set represented in the 
message is compared against the set of available labels at the 
downstream interface and the resulting intersecting Label Set is 
forwarded in a REQUEST message. When the resulting Label Set is 
empty, the REQUEST must be terminated, and a NOTIFICATION message, 
and a "Routing problem/Label Set" indication MUST be generated. Note 
that intersection is based on the physical labels (actual 
wavelength/band values) which may have different logical values on 
different links, as a result it is the responsibility of the node to 
map these values so that they have a consistent physical meaning, or 
to drop the particular values from the set if no suitable logical 
label value exists. 


When processing a MAPPING message at an intermediate node, the label 
propagated upstream MUST fall within the Label Set. 
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Note, on reception of a MAPPING message a node that is incapable of 
performing label conversion has no other choice than to use the same 
physical label (wavelength/band) as received in the MAPPING message. 
In this case, the use and propagation of a Label Set will 
significantly reduce the chances that this allocation will fail. 


3. Bidirectional LSPs 


Bidirectional LSP setup is indicated by the presence of an Upstream 
Label in the REQUEST message. An Upstream Label has the same format 
as the generalized label, see Section 2.2. Upstream Label uses type 
= 0x0826. 


3.1. Procedures 


The process of establishing a bidirectional LSP follows the 
establishment of a unidirectional LSP with some additions. To 
support bidirectional LSPs an Upstream Label is added to the REQUEST 
message. The Upstream Label MUST indicate a label that is valid for 
forwarding at the time the REQUEST message is sent. 


When a REQUEST message containing an Upstream Label is received, the 
receiver first verifies that the upstream label is acceptable. If 
the label is not acceptable, the receiver MUST issue a NOTIFICATION 
message with a "Routing problem/Unacceptable label value" indication. 
The generated NOTIFICATION message MAY include an Acceptable Label 
Set, see Section 4. 


An intermediate node must also allocate a label on the outgoing 
interface and establish internal data paths before filling in an 
outgoing Upstream Label and propagating the REQUEST message. If an 
intermediate node is unable to allocate a label or internal 
resources, then it MUST issue a NOTIFICATION message with a "Routing 
problem/Label allocation failure" indication. 


Terminator nodes process REQUEST messages as usual, with the 
exception that the upstream label can immediately be used to 
transport data traffic associated with the LSP upstream towards the 
initiator. 


When a bidirectional LSP is removed, both upstream and downstream 


labels are invalidated and it is no longer valid to send data using 
the associated labels. 
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4. Notification on Label Error 


This section defines the Acceptable Label Set TLV to support 
Notification on Label Error per [RFC3471]. An Acceptable Label Set 
TLV uses a type value of 0x082a. The remaining contents of the TLV 
have the identical format as the Label Set TLV, see Section 2.5. 


Acceptable Label Set TLVs may be carried in NOTIFICATION messages. 
The procedures for defining an Acceptable Label Set follow the 
procedures for defining a Label Set, see Section 2.5.1. 

Specifically, an Acceptable Label Set is defined via one or more 
Acceptable Label Set TLVs. Specific labels/subchannels can be added 
to or excluded from an Acceptable Label Set via Action zero (0) and 
one (1) TLVs respectively. Ranges of labels/subchannels can be added 
to or excluded from an Acceptable Label Set via Action two (2) and 
three (3) TLVs respectively. When the Acceptable Label Set TLVs only 
list labels/subchannels to exclude, this implies that all other 
labels are acceptable. 


The inclusion of Acceptable Label Set TLVs is optional. If included, 
the NOTIFICATION message SHOULD contain a "Routing 
problem/Unacceptable label value" indication. The absence of 
Acceptable Label Set TLVs does not have any specific meaning. 


5. Explicit Label Control 
The Label ER-Hop TLV is defined as follows: 
0 1 2 3 


O1L2a3 459 6789 0123456789 012345678 9 021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


|o|o| Type (0x0829) | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|L |u| Reserved | Label 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Label (continued) | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

See [RFC3471] for a description of L, U and Label parameters. 
5.1. Procedures 

The Label ER-Hop follows a ER-Hop containing the IP address, or the 

interface identifier [MPLS-UNNUM], associated with the link on which 

it is to be used. Up to two label ER-Hops may be present, one for 


the downstream label and one for the upstream label. The following 
SHOULD result in "Bad EXPLICIT_ROUTE" errors: 
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fe) If the first label ER-Hop is not preceded by a ER-Hop containing 
an IP address, or a interface identifier [MPLS-UNNUM], associated 
with an output link. 

o For a label ER-Hop to follow a ER-Hop that has the L-bit set. 

fe) On unidirectional LSP setup, for there to be a label ER-Hop with 
the U-bit set. 

fe) For there to be two label ER-Hops with the same U-bit values. 


To support the label ER-Hop, a node must check to see if the ER-Hop 
following its associate address/interface is a label ER-Hop. If it 
is, one ER-Hop is examined for unidirectional LSPs and two ER-Hops 
for bidirectional LSPs. If the U-bit of the ER-Hop being examined is 
clear (0), then value of the label is copied into a new Label Set 
TLV. This Label Set TLV MUST be included on the corresponding 
outgoing REQUEST message. 


If the U-bit of the ER-Hop being examined is set (1), then value of 
the label is label to be used for upstream traffic associated with 
the bidirectional LSP. If this label is not acceptable, a "Bad 
EXPLICIT_ROUTE" error SHOULD be generated. If the label is 
acceptable, the label is copied into a new Upstream Label TLV. This 
Upstream Label TLV MUST be included on the corresponding outgoing 
REQUEST message. 


After processing, the label ER-Hops are removed from the ER. 


Note an implication of the above procedures is that the label ER-Hop 
should never be the first ER-Hop in a newly received message. If the 
label ER-Hop is the first ER-Hop an a received ER, then it SHOULD be 
treated as a "Bad strict node" error. 


Procedures by which an LSR at the head-end of an LSP obtains the 
information needed to construct the Label ER-Hop are outside the 
scope of this document. 


6. Protection TLV 


The use of the Protection TLV is optional. The TLV is included to 
indicate specific protection attributes of an LSP. 


The format of Protection Information TLV is: 
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0 Í 2 3 

Oo S E O A 7 8+ O06 E E E 6 8 90-1. 2 3 A O 8 OO 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
|u|F| Type (0x0835) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++H+++ 
|s] Reserved | Link Flags| 
Hato bo toto tatatatoto toto ta tatatatatotiteo to tatatitotitototetetatat 


See [RFC3471] for a description of parameters. 


6.1. Procedures 


Transit nodes processing a REQUEST message containing a Protection 
TLV MUST verify that the requested protection can be satisfied by the 
outgoing interface or tunnel (FA). If it cannot, the node MUST 
generate a NOTIFICATION message, with a "Routing problem/Unsupported 
Link Protection" indication. 


7. Administrative Status Information 


Administrative Status Information is carried in the Admin Status TLV. 
The TLV provides information related to the administrative state of a 
particular LSP. The information is used in two ways. In the first, 
the TLV is carried in REQUEST and MAPPING messages to indicate the 
administrative state of an LSP. In the second, the TLV is carried in 
Notification message to request a change to the administrative state 
of an LSP. 


7.1. Admin Status TLV 


The use of the Admin Status TLV is optional. It uses Type = 0x082b. 
The format of the TLV is: 


The format of Admin Status TLV in REQUEST, MAPPING and Notification 
Messages is: 


0 1 2 3 
QST 2 3. 4-5) 16. F895 01-2 3) 45-67 8 9 OL 23-45. 16 7 -B2°95.0: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|u|F| Type (0x082b) | Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|R] Reserved |T|A|D| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


See [RFC3471] for a description of parameters. 


Ashwood-Smith & Berger Standards Track [Page 11] 


RFC 3472 GMPLS Signaling - CR-LDP Extensions January 2003 


7.2. REQUEST and MAPPING Message Procedures 


The Admin Status TLV is used to notify each node along the path of 
the status of the LSP. Each node processes status information based 
on local policy and then propagated in the corresponding outgoing 
messages. The TLV is inserted in REQUEST messages at the discretion 
of the ingress node. The absence of the TLV is the equivalent to 
receiving a TLV containing values all set to zero. 


Transit nodes receiving a REQUEST message containing an Admin Status 
TLV, update their local state, take any appropriate local action 
based on the indicated status and then propagate the received Admin 
Status TLV in the outgoing REQUEST message. 


Edge nodes receiving a REQUEST message containing an Admin Status 
TLV, also update their local state and take any appropriate local 
action based on the indicated status. When the ADMIN Status TLV is 
received with the R bit set, the receiving edge node should reflect 
the received values in a corresponding MAPPING message. 

Specifically, if an egress node receives a Request message with the R 
bit of the Admin_Status TLV set and the node the node SHOULD send a 
Mapping message containing an Admin_Status TLV with the same values 
set, with the exception of the R bit, as received in the 
corresponding Request message. 


7.2.1. Deletion procedure 


In some circumstances, particularly optical networks, it is useful to 
set the administrative status of an LSP before tearing it down. 


In such circumstances the procedure SHOULD be followed when deleting 
an LSP from the ingress: 


(0) The ingress node precedes an LSP deletion by inserting an Admin 
Status TLV in a Notification Message setting the Reflect (R) and 
Delete (D) bits. 


fe) Transit nodes process the Admin Status TLV by passing the 
Notification message. The egress node May respond with a 
Notification message with the Admin Status TLV. 


(0) Upon receiving the Admin Status TLV with the Delete (D) bit set 
in the Notification message, the egress SHOULD respond with a 
LABEL WITHDRAW message and normal CR-LDP processing takes place. 


In such circumstances the procedure SHOULD be followed when deleting 
an LSP from the egress: 
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(0) The egress node indicates its desire for deletion by inserting an 
Admin Status TLV in a Notification message and setting Delete (D) 
bit. 

fe) Transit nodes process the Admin Status TLV as described above. 


fe) Upon receiving the Admin Status TLV with the Delete (D) bit set 
in the Notification message, the ingress node sends a LABEL 
RELEASE message downstream to remove the LSP and normal CR-LDP 
processing takes place. 


7.3. Notification Message Procedures 


Subsequent messaging Admin Status messaging may be performed by 
Notification Messages. The ingress may begin the propagation of a 
Notification Message with an Admin Status TLV. Each subsequent node 
propagates the Notification with the Admin Status TLV from the 
ingress to the egress and then the egress node returns the 
Notification messages back Upstream carrying the Admin Status TLV. 


Intermediate and egress nodes may trigger the setting of 
administrative status via the use of Notification messages. To 
accomplish this, an intermediate or egress node generates a 
Notification message with the corresponding upstream notify session 
information. The Admin Status TLV MUST be included in the session 
information, with the appropriate bit or bits set. The Reflect (R) 
bit MUST NOT be set. 


An ingress or egress node receiving a Notification message containing 
an Admin Status TLV with the Delete (D) bit set, SHOULD initiate the 
deletion procedure described in the previous section. 


7.3.1. Compatibility and Error Procedures 


Some special processing is required in order to cover the case of 
nodes that do not support the Admin Status TLV and other error 
conditions. Specifically, a node that sends a Notification message 
containing an Admin Status TLV with the Down (D) bit set MUST verify 
that it receives a corresponding LABEL RELEASE message within a 
configurable period of time. By default this period of time SHOULD 
be 30 seconds. If the node does not receive such a LABEL RELEASE 
message, it SHOULD send a Label Release message downstream and a 
LABEL WITHDRAW message upstream. 
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8. Control Channel Separation 


This section provides the protocol specific formats and procedures to 
required support a control channel not being in-band with a data 
channel. 


8.1. Interface Identification 


The choice of the data interface to use is always made by the sender 
of the REQUEST message. The choice of the data interface is 
indicated by the sender of the REQUEST message by including the data 
channel’s interface identifier in the message using a new Interface 
TLV type. For bidirectional LSPs, the sender chooses the data 
interface in each direction. In all cases but bundling, the upstream 
interface is implied by the downstream interface. For bundling, the 
REQUEST sender explicitly identifies the component interface used in 
each direction. 


8.1.1. Interface ID TLV 
The format of IPV4 Interface ID in REQUEST, MAPPING Messages is: 


0 Í 2 3 

012 3:45 673 901 2 3A 5 6 789 012 34-5 67 8 9 0 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type (0x082d) | Length | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
IPv4 Next/Previous Hop Address | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Logical Interface ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Interface ID TLVS see [RFC3471] | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


l 
+ 
| 


IG 
+ — 
1 
+—+ 


+— + — +—+— + 


The format of IPV6 Interface ID TLV in REQUEST, MAPPING Messages is: 


0 1 2 3 
Od. 2 3+ 4H 9) 16 88950 12 3) A568 8 Se OL 2S 4a 168 FB 879 Oi 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
U|F| Type (0x082e) | Length 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++++HH 


IPv6 Next/Previous Hop Address | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Logical Interface ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Interface ID TLVS see [RFC3471] | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + — +— ++ 
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See [RFC3471] for a description of parameters. 


See [RFC3212] for a description of signaling address. See [RFC3471] 
for a description of parameters and encoding of TLVs. 


8.1.2. Procedures 


An IF_ID TLV is used on links where there is not a one-to-one 
association of a control channel to a data channel, see [RFC3471]. 


The LDP session uses the IF_ID TLV to identify the data channel(s) 


associated with the LSP. For a unidirectional LSP, a downstream data 
channel MUST be indicated. For bidirectional LSPs, a common 
downstream and upstream data channel is normally indicated. In the 


special case where a bidirectional LSP that traverses a bundled link, 
it is possible to specify a downstream data channel that differs from 
the upstream data channel. Data channels are specified from the 
viewpoint of the sender of a REQUEST message. The IF_ID TLV SHOULD 
NOT be used when no TLVs are needed. 


A node receiving one or more IF_ID TLVs in a REQUEST message saves 
their values and returns them in the subsequent MAPPING message sent 
to the node that originated the TLVs. 


Note, the node originating an IF_ID TLV MUST ensure that the selected 
outgoing interface, as specified in the IF_ID TLV, is consistent with 
an ERO. A node that receives an IF_ID TLV SHOULD check whether the 
information carried in this TLV is consistent with the information 
carried in a received ERO, and if not it MUST send a LABEL ABORT 
Message with the error code "Routing Error" and error value of "Bad 
Explicit Routing TLV Error" toward the sender. This check CANNOT be 
performed when the initial ERO subobject is not the incoming 
interface. 


8.2. Errored Interface Identification 


There are cases where it is useful to indicate a specific interface 
associated with an error. To support these cases the IF_ID Status 
TLV are defined. 
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8.2.1. IF_ID Status TLVs 
The format of the IPv4 IF_ID Status TLV is: 


0 1 2 3 
Oud: 23.456 7 8. 90 A 23 45.6 7 8: 9-0 1 2-3 456 78 9-0 <1 
+-t—4+-F-4-4F-4-F-4-F-4-F-4-F-4-F ot ta tt ati tat tatitatitatitatitat 

|u|F| Type (0x082f) | Length 
toto4t-F—4-4F-4-4F-4-4F-4-F-4-F tt atta t atta titi titi titatitatitat 
| IPv4 Next/Previous Hop Address 
toto4t-F—4-4F-4-F-4-F-4-F-4-F-4-F Ht ta t-ta tito titi ti tititatitatitat 
| Status Code | 
tot—4+-F-4-4F-4-F-4-F-4-F-4-F-4-F-t-ti tt atta ti tattatitatitatitat 
| | 


a TLVs = 


+-+-4-4+-+-+4+-4+-+-+-4+-4+-+-4+-4+-4+-+4+-4-4+-+4-4-4+-4+-4+-4+-4+-4+-4+-4+-+-4+-4-4-4+ 
The format of the IPv6 IF_ID Status TLV is: 


0 1 2 3 
On 2 SHA SOG FH Be G0 Tre A 6 8 ir 0 1, 23 eG B90 I 
tata tata ta tata tata tata tata ta tata tata ta tata ta tata tata tata tatatatat 

|u|F| Type (0x0830) | Length 
tata ta tata tata tata ta tata ta tata ta ta tata tata ta ta tata HH 


IPv6é Error Node Address | 


nS Sn Sn SS Ss ee ee ee 
| Status Code | 
Fatt tata tata tata tartan tata tata tattoo HMHHMHHMHHMHH 


TLVs 2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


See [RFC3036] for a description of status code value fields. See 
[RFC3471] for a description of parameters and encoding of TLVs. 


8.2.2. Procedures 


Nodes wishing to indicate that an error is related to a specific 
interface SHOULD use the appropriate IF_ID Status TLV in the 
corresponding LABEL WITHDRAW or LABEL RELEASE message. IF_ID Status 
TLV SHOULD be generated and processed as any other Status TLV, see 
[RFC3036]. 
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9. Fault Handling 


In optical transport networks, failures in the out-of-fiber signaling 
communication or optical control plane should not have service impact 
on the existing optical connections. Under such circumstances, a 
mechanism MUST exist to detect a signaling communication failure and 
a recovery procedure SHALL guarantee connection integrity at both 
ends of the signaling channel. 


The LDP Fault tolerant document [LDP-FT] specifies the procedures for 
recovering LDP and CR-LDP sessions under failure. Please refer to 
his document for procedures on recovering optical connections. 
Currently the Fault tolerant document covers many of the common 
failure modes for a separated control and data plane. 
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Generalized Label Request (TLV 0x0824) 
Generalized Label (TLV 0x0825) 
Upstream Label (TLV 0x0826) 

Label Set (TLV 0x0827) 

Waveband Label (TLV 0x0828) 

ER-Hop (TLV 0x0829) 

Acceptable Label Set (TLV 0x082a) 
Admin Status (TLV 0x082b) 
Interface ID (TLV 0x082c) 
IPV4 Interface ID (TLV 0x082d 
IPV6 Interface ID (TLV 0x082e 
IPv4 IF_ID Status (TLV 0x082f 
IPv6 IF_ID Status (TLV 0x0830 
Protection (TLV 0x0835) 


) 
) 
) 
) 
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13. Intellectual Property Considerations 
This section is taken from Section 10.4 of [RFC2026]. 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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17. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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